Method and apparatus for storing and distributing encryption keys

ABSTRACT

A method of key distribution includes generating, by a first system device ( 101 ), key material and forwarding the key material from the first system device ( 101 ) to a second system device ( 107 ). It is determined whether a mobile station ( 401 ), for which the key material is directed, is active on the system. When the mobile station is active, the key material is forwarded to a base station ( 115 ) where the mobile station ( 401 ) is active, and the base station ( 115 ) forwards the key material to the mobile station ( 401 ).

FIELD OF THE INVENTION

[0001] This invention relates to encrypted communications, including butnot limited to air interface communication within secure communicationsystems.

BACKGROUND OF THE INVENTION

[0002] Encrypted voice and data systems are well known. Many of thesesystems provide secure communication between two or more users bysharing one piece of information between the users, which permits onlythose users knowing it to properly decrypt the message. This piece ofinformation is known as the encryption key variable, or key for short.Loading this key into the actual encryption device in the securecommunication unit is a basic requirement that allows securecommunication to occur. To retain security over a long period of time,the keys are changed periodically, typically weekly or monthly.

[0003] Encryption is known to be performed on an end-to-end basis withina communication system, i.e., encrypting a message at the originatingcommunication unit (also known as a mobile station), passing ittransparently (i.e., without decryption) through any number of channelsand/or pieces of infrastructure to the end user's communication unit,which decrypts the message.

[0004] The Terrestrial Trunked Radio (TETRA) communication standard ispresently utilized in Europe (hereinafter TETRA Standard), withpotential for expansion elsewhere. The TETRA Standard calls for airinterface, also known as air traffic or over-the-air, encryption. Airinterface encryption protects information on the air interface betweenthe infrastructure and the mobile subscriber. The TETRA standard callsfor an authentication center, also known as a key management facility orkey management center, to generate, distribute, and authenticateencryption keys and users. The TETRA standard does not, however, specifyhow to implement an authentication center, nor how to generate,distribute, and authenticate key material to system devices or mobilestations for information traversing through the infrastructure or SwMI(Switching and Management Infrastructure), as it is referred to in theTETRA Standard.

[0005] The TETRA standard fails to provide definition to minimize burdento call processing and bandwidth, provide encryption and authenticationin a manner tolerant to equipment faults, support wide-areacommunications, and to store keys for all communication units withoutundue storage burden at local sites.

[0006] Accordingly, there is a need for a method and apparatus forproviding a secure infrastructure for a communication system thatutilizes air interface encryption and generates, distributes, andauthenticates encryption keys and users without causing undue burden tocall processing, bandwidth, security, and storage.

BRIEF DESCRIPTION OF THE DRAWINGS

[0007]FIG. 1 is a block diagram of a secure communication system inaccordance with the invention.

[0008]FIG. 2 is a block diagram showing key distribution pools inaccordance with the invention.

[0009]FIG. 3 and FIG. 4 are block diagrams showing key storage within acommunication system in accordance with the invention.

[0010]FIG. 5 is a diagram showing key storage and authenticationinformation distribution within a communication system in accordancewith the invention.

[0011]FIG. 6 is a diagram showing authentication information storage andauthentication decision making within a communication system inaccordance with the invention.

[0012]FIG. 7 is a diagram showing authentication of a mobile station byan authentication center in accordance with the TETRA Standard.

[0013]FIG. 8 is a diagram showing authentication of an authenticationcenter by a mobile station in accordance with the TETRA Standard.

[0014]FIG. 9 is a diagram showing key storage and authenticationinformation distribution between a communication system and a mobilestation in accordance with the invention.

[0015]FIG. 10 is a diagram showing a key pull within a communicationsystem in accordance with the invention.

[0016]FIG. 11 is a diagram showing a key push within a communicationsystem in accordance with the invention.

[0017]FIG. 12 is a diagram showing distribution of a static cipher keyto a base station within a communication system in accordance with theinvention.

[0018]FIG. 13 is a diagram showing distribution of a static cipher keyto a mobile station within a communication system in accordance with theinvention.

[0019]FIG. 14 is a diagram showing distribution of a common cipher keyto a mobile station and a base station within a communication system inaccordance with the invention.

[0020]FIG. 15 is a diagram showing distribution of a group cipher key toa base station within a communication system in accordance with theinvention.

[0021]FIG. 16 is a diagram showing distribution of a group cipher key toa mobile station within a communication system in accordance with theinvention.

[0022]FIG. 17 is a flowchart showing a method of key persistence at asite in a communication system in accordance with the invention.

DESCRIPTION OF A PREFERRED EMBODIMENT

[0023] The following describes an apparatus for and method of providinga secure infrastructure for a communication system that utilizes airinterface encryption and generates, distributes, and authenticatesencryption keys and users without causing undue burden to callprocessing, bandwidth, security, and storage. System devices are dividedinto groups or pools and encryption keys are defined to provide securetransfer of key material among the system devices.

[0024] A block diagram of a secure communication system that iscomprised of a plurality of zones is shown in FIG. 1. The securecommunication system is comprised of a plurality of system devices thatcomprise the infrastructure of the system. A Key Management Facility(KMF) 101 transfers security data, such as session authenticationinformation and encryption keys, to a User Configuration Server (UCS)103, that forwards the information and data to the appropriate zonebased on configuration data within the UCS 103. Communications for afirst zone are provided by a plurality of system devices including aZone Manager (ZM) 105, a Zone Controller 107 that includes a HomeLocation Register (HLR) 109 and a Visited (also known as a Visitor orVisitors') Location Register (VLR) 111, an air traffic router (ATR) 113,and a plurality of base stations (BSs) 115 and 117 located at aplurality of communication sites within the first zone. Communicationsfor a second zone are provided by a plurality of system devicesincluding a ZM 119, a ZC 121 that includes an HLR 123 and a VLR 125, anATR 127, and a plurality of BSs 129 and 131 located at a plurality ofcommunication sites within the second zone. The BSs 115, 117, 129, and131 communicate with a plurality of mobile stations (see FIG. 4). TheZCs 107 and 121 communicate via a network 133, such as a local areanetwork or a wide area network such as an IP (internet protocol)network. Only two zones and their associated system devices are shownfor the sake of simplicity, although any number of zones may besuccessfully incorporated in the secure communication system.

[0025] For the sake of simplicity, not all system devices will be shownin each Figure, but rather a representative set of system devices thatillustrates a particular concept will be provided. Similarly, not allkey material is shown stored in each system device for the sake ofspace. Each message containing a key, key material, configuration, orother information is transferred with an related identity (ID) such asITSI or GTSI, although the ID is generally not shown in the drawings forspace considerations.

[0026] The KMF 101 is a secure entity that stores the authentication key(K) for each mobile station (MS) or communication unit, such as aportable or mobile two-way radio, Direct Mode Operation (DMO) gateway,receiver, scanner, or transmitter (for example, see devices 401, 403,and 405 in FIG. 4). The KMF 101 provides a random seed (RS) andassociated session authentication keys (KS and KS′) for each mobilestation associated with the secure communication system. The KMF 101also imports/generates various air interface keys, such as Static CipherKey (SCK), Group Cipher Key (GCK), and Common Cipher Key (CCK), fordistribution in the system. The KMF 101 functions as the authenticationcenter (AuC), as referred to in the TETRA communication standard, in thesystem. Typically, there is one KMF server per system, although theremay be one or more KMF clients per system.

[0027] The UCS 103 is a single point of entry for configuration data inthe system. In the preferred embodiment, the UCS 103 stores anddistributes session authentication information, such as RS, KS, and KS′,to the appropriate home zone in the system. The UCS 103 functions as anon-real time distribution point for session authentication informationin the system.

[0028] The ZM 105 or 119 is a management database for a zone. In thepreferred embodiment, the ZM 105 or 119 stores session authenticationinformation, such as RS, KS, and KS′, for the zone managed by theparticular ZM 105 or 119. The ZM functions as a non-real time storagefacility for authentication information in the zone.

[0029] The ZC 107 or 121 performs real time authentication for themobile stations in its zone. The ZC uses the session authenticationinformation, such as RS, KS, and KS′, to perform the real-timeauthentication. The HLR 109 or 123 stores session authenticationinformation for each MS that has the HLR 109 or 123 as its home. The VLR111 or 125 stores session authentication information for each MSvisiting the VLR's 111 or 125 zone. The ZC 107 or 121 performs real-timedistribution of its home mobile stations' session authenticationinformation when the MS roams outside its home zone. In the preferredembodiment, an HLR 109 or 123 and VLR 111 or 125 are part of each zonecontroller and perform on behalf of the same zone for which the zonecontroller is associated. The HLR 109 or 123 and VLR 111 or 125 may bepart of other system devices or may be stand alone devices. The derivedcipher key (DCK) is generated during authentication. The ZC 107 or 121generates and distributes the DCK for the MS to the BSs 115, 117, 129,and 131 that require the DCK for secure communications.

[0030] The ATR 113 or 127 is the conduit used by the KMF 101 to sendrekey messages or key updates to an MS, such as SCK and GCK. The KMF 101sends key updates for mobile stations to the home zone ATR 113 or 127for dissemination. All rekey acknowledgments (ACKs), whetherinfrastructure or MS originated, pass through the ATR 113 or 127 to theKMF 101.

[0031] Each BS 115, 117, 129, and 131 receives and transmitsauthentication messages over the air interface. Each BS 115, 117, 129,and 131 acts as a transmitter for its associated ZC 107 or 121 and as areceiver for the MS in the system. The BS 115, 117, 129, or 131 uses DCKfor air interface encryption with the MS. The BSs 115, 117, 129, and 131are responsible for sending key material to the MSs 401, 403, 405, and407. The result of some of these operations (SCK, GCK) is sent back tothe KMF 101. Because each base site is comprised substantially of one ormore base stations, the terms base site (or site) and base station areused interchangeably herein, both sharing the acronym BS. In thepreferred embodiment, a TETRA site Controller (TSC) connects all thebase stations at a site, stores key material, and distributes keymaterial to the base stations as needed, thereby making keys availableto all base stations at a site. Thus, when a key is said to be stored ata base station or a base site, in the preferred embodiment, the TSCactually provides storage for the base station for key material. Becausekey storage and distribution and other key-related functions may beperformed by a base site, base station, or TSC, these terms areconsidered interchangeable for the purposes of this document.

[0032] The Mobile Station (MS) authenticates the system and/or isauthenticated by the system using a challenge-response protocol. Each MShas its own key, K, for use during authentication. Each MS is assignedto one HLR, which typically remains the same. Each MS is also associatedwith only one VLR in the zone in which the MS is presently located. AnMS is not registered on a system until the MS is active and has passedauthentication.

[0033]FIG. 2 is a block diagram showing key distribution pools. Using asingle key encryption key (KEK) to encrypt keys for distribution systemwide is a convenient choice, although a single KEK would result indegraded security due to the higher likelihood that the KEK would becompromised and the resultant compromise would affect the whole system.Using a different KEK for each system device would be more secure, butwould burden storage within system devices and add unnecessary delays tocall processing. FIG. 2 shows a system for using KEKs that is moresecure than a single system-wide key, yet not as burdensome as adifferent KEK for each system device. Two types of KEKs are assigned toconfidentially distribute key material (such as air interface keys,session authentication information, data utilized to generate encryptionkeys, and other key-related material) to the system devices of theinfrastructure of a system: intrakeys and interkeys. KEKs are 80 bits inthe preferred embodiment.

[0034] The first type of KEK is an intrakey, also referred to as anintrapool key or intra-zone key, KEK_(Z). The system devices are dividedinto pools or groups 201, 203, 205, and 207. Each pool is assigned itsown unique intrakey, KEK_(Z). In the preferred embodiment, each pool ofdevices corresponds to a zone in the communication system, and each poolhas a mutually exclusive collection of system devices, i.e., each systemdevice only belongs to one pool. The first pool 201 utilizes KEK_(Z1) toencrypt key material, such as encryption keys and/or sessionauthentication information, for transfer within the first pool (or zonein the preferred embodiment) and comprises the first zone controller ZC1107 and its associated BSs 115, 117, and 211. The second pool 203utilizes KEK_(Z2) to encrypt key material for transfer within the secondpool (or zone in the preferred embodiment) and comprises the second zonecontroller ZC2 121 and its associated BSs 129, 131, and 213. The thirdpool 205 utilizes KEK_(Z3) to encrypt key material for transfer withinthe third pool (or zone in the preferred embodiment) and comprises thethird zone controller ZC3 223 and its associated BSs 225, 227, and 229.The fourth pool 207 utilizes KEK_(Z4) to encrypt key material fortransfer within the fourth pool (or zone in the preferred embodiment)and comprises the fourth zone controller ZC4 215 and its associated BSs217, 219, and 221. In the preferred embodiment, the intrakey is used bya zone controller to distribute key material to base sites/base stationswithin its zone. KEK_(Z) is also used by the KMF 101 to distribute SCK.

[0035] The second type of KEK is an interkey, KEK_(M), also referred toas an interpool key or inter-zone key. The interkey is used to encryptkey material sent between pools or zones in the preferred embodiment, orwithin a certain group 209 of system devices, particularly from the KMF101. In the preferred embodiment, the interkey is used by the KMF 101 todistribute GCK and individual authentication information to theinfrastructure. In the preferred embodiment, the interkey is stored inone system device in each zone, in each zone controller 107 and 121, andis also stored in the KMF 101. The connections shown between the KMF 101and the zone controllers 107, 121, 215, and 223 are virtual connectionsin the preferred embodiment, in that other devices, such as the UCS 103and ZMs 105 and 119, are physically located between the KMF 101 and zonecontrollers 107, 121, 215, and 223. The UCS 103 and ZMs 105 and 119 passencrypted key information in a transparent manner between the KMF 101and zone controllers 107, 121, 215, and 223, i.e., the UCS 103 and ZMs105 and 119 do not decrypt or encrypt the information, thus no storageof a KEK is required at the UCS 103 and ZMs 105 and 119, although keymaterial may be stored in encrypted form at the UCS 103 and ZMs 105 and119.

[0036] Preferably, a message is encrypted by one of an intrakey and aninterkey, typically using TA31 (decrypted using TA32), based on a systemdevice to which the message is forwarded. For example, when the messageis intended for a system device in a zone other than the zone containingthe sending device, the interkey is used. When the message is intendedfor a system device in the same zone as the zone containing the sendingdevice, the intrakey is used. In the preferred embodiment, when the KMF101 encrypts key material, such as SCK, CCK, SAI, and GCK, with eitherthe interkey or intrakey, the KMF 101 uses TA31.

[0037] For example, from time to time, key material is distributed fromthe HLR to a VLR and then to the base sites within the zone of the VLR.In this case, the key material is encrypted by KEK_(M) and passedtransparently from HLR to VLR. The target VLR decrypts the key materialusing its KEK_(M) and re-encrypts it with the KEK_(Z) of the zone fordistribution to sites within the zone.

[0038] Each system device that contains an infrastructure KEK has itsown unique infrastructure or protection key, KI, in the preferredembodiment. The protection key is only utilized to decrypt/encrypt KEKssent by the KMF 101 to the infrastructure system devices. Preferably,the KI is only able to be loaded by a key variable loader and is notable to be updated with an OTAR (over-the-air rekey) operation. Inaddition to distribution by the KMF 101, the KEKs may also be manuallyprovided with a Key Variable Loader. KI is 128 bits long in thepreferred embodiment.

[0039] As shown in Table 1 below, KEK_(M) is only stored by the zonecontrollers 107 and 121 and the KMF 101. The intrakey KEK_(Z) is heldonly by the KMF 101, base stations/sites, and zone controller 107 and121 within each zone. Each zone has a unique KEK_(Z). Each system devicehas its own KI. TABLE 1 Distribution of Key Encryption Key TypesInfrastructure Element Zone 1 Zone 2 Zone Controller (HLR, VLR) KI₁,KEK_(M), KEK_(Z1) KI₂, KEK_(M), KEK_(Z2) Base Sites KI₃, KEK_(Z1) KI₄,KEK_(Z2)

[0040] The use of intrakeys and interkeys strikes a unique tradeoffbetween security and key management complexity as well as speed of callprocessing. The KMF 101 need only maintain one interkey plus oneintrakey for each pool or zone in the system. If a KEK_(Z) iscompromised, the affect and response is localized to that zone, ratherthan the whole system, and KI remains intact to redistribute a newKEK_(Z) to that zone. KEK_(M) is stored only at the KMF 101 and the HLR109 and 123 and VLR 111 and 125 in each zone, which devices aretypically more physically protected from an attack. If KEK_(M) iscompromised, the KMF 101 changes KEK_(M) in the ZCs 107 and 121, leavingthe sites unaffected.

[0041] Five basic types of air interface keys are used to encrypt airinterface traffic in the secure communication system: a Static CipherKey (SCK), a Common Cipher Key (CCK), a Group Cipher Key (GCK), aDerived Cipher Key (DCK), and a Modified Group Cipher Key (MGCK). Threebasic types of keys are used between the system devices: anInfrastructure Key (KI) also known as a protection key, an inter-zone orinter-pool key encryption key also known as an interkey (KEK_(M)), andan intra-zone or intra-pool key encryption key also known as an intrakey(KEK_(Z)).

[0042] The Static Cipher Key (SCK) is the most basic of the airinterface keys and is used to encrypt inbound (MS to infrastructure) andoutbound (infrastructure to MS) information when authentication and/ordynamic air interface encryption is not available. Thus, the generationand distribution of this key has no relation to authentication.

[0043] The Derived Cipher Key (DCK) is a session key derived within theauthentication procedure. The DCK changes each time an authentication isperformed with the MS and the infrastructure, also called the SwMI inthe TETRA Standard. The DCK is used for inbound traffic encryption. TheDCK is also used for outbound individually addressed traffic to the MS.DCK is used when using dynamic air interface encryption operating inTETRA Standard security class 3.

[0044] This Common Cipher Key (CCK) is a group key in the sense thatmultiple MSs have the same CCK. Unlike the GCK, however, the CCK has norelation to a particular talkgroup (TG). The CCK is geographicallyspecific, i.e., the CCK serves all units within a given location area.The location area as defined in the TETRA standard may be as small as asite or a big as an entire system. Each unit within a location area usesthe same CCK. Group communications in the outbound direction use CCKwhen there is no GCK/MGCK available for that group call. CCK is used forthe encryption of outbound group traffic and identities only. Inboundidentities are encrypted with CCK when DCK is in use.

[0045] Indirectly, the Group Cipher Key (GCK) is used to encryptoutbound talkgroup calls. In the preferred embodiment, a GCK is definedfor each talkgroup in the system. Actually, the GCK is only indirectlyused for the encryption of traffic information; the modified groupcipher key (MGCK), which is a derivative of the GCK, is directly usedfor traffic encryption. GCK is never used for the actual encryption oftraffic as it is considered a long term key.

[0046] The Modified Group Cipher Key (MGCK) is used to encrypt outboundtalkgroup call traffic. MGCK is formed by the combination of GCK andCCK. Each GCK has a corresponding MGCK defined in for a location area.

[0047] Each infrastructure element has an infrastructure or protectionkey, KI, that is used as the encryption key for any infrastructure keyencryption key updates. KI is similar in function to the authenticationkey, K, in a mobile station. In the preferred embodiment, KI is updatedonly by a provisioning device such as a key variable loader. In thepreferred embodiment, infrastructure key encryption key (KEK) updatescannot be performed without this key.

[0048] Each zone controller has an interkey, KEK_(M), also referred toas an inter-zone or inter-pool key, which is used to encrypt all keytraffic passed between the KMF and each zone. KEK_(M) is also used bythe zone controller to pass GCK, CCK, and DCK, as well as sessionauthentication information, between zones. In the preferred embodiment,one KEK_(M) is present in the KMF and each of the zone controllers ineach system.

[0049] Each zone has its own intrakey, KEK_(Z), also referred to as anintra-zone or intra-pool key. The intrakey is used to encrypt all keytraffic within the zone, between the zone controller and each of thesites within the zones. Each base site and zone controller has the sameKEK_(Z) in a zone. The KMF stores the KEK_(Z) for each zone in thesystem.

[0050] A method of the present invention establishes an expectedlifetime, or rekey interval, for an encryption key. Table 2 below showsexample rekey intervals for each key stored in the secure communicationsystem. When the expected lifetime for an encryption key expires, i.e.,when the rekey interval occurs, the encryption key is replaced.

[0051] A number of storage locations for each type of system devicewithin a communication system is determined. For example, one KMF 101,one UCS 103, one ZM 105 or 119 per zone, one zone controller 107 or 121per zone, one HLR 109 or 123 per zone, one VLR 111 or 125 per zone, anda number of sites and corresponding base stations per site depending onthe coverage requirements for each zone. Based on the expected lifetimefor each encryption key and the number of storage locations for eachsystem device, a type of system device is assigned to store eachencryption key, and the encryption keys are stored at the system deviceof the assigned type. For example, derived cipher keys are stored atbase stations and in the HLR/VLR, common cipher keys are stored at basestations, modified group cipher keys are stored at base stations, andgroup cipher keys that are stored at HLRs and VLRs.

[0052] Table 2 shows the target (user) of each key and the rekeyinterval, i.e., time between changes or updates of the specific key in apreferred embodiment. For example, the MGCK, which is a combination ofCCK and GCK, is updated whenever CCK is changes and whenever GCK ischanged. Table 2 may be changed by the KMF operator. TABLE 2 KEY TARGETREKEY INTERVAL SCK All MS, all BS 1 year/or if compromised DCK MS, BS,HLR, VLR <24 hrs, whenever unit authenticates CCK group (TG HLR), allMS, all 24 hrs BS GCK group (TG HLR) 6 months MGCK group (BS, MS) 24hrs-Minimum of CCK, GCK interval KI All devices using KEK_(Z) or Neverchanges KEK_(M) (BS, ZC) KEK_(Z) zone 6 months/or if compromised KEK_(M)system 6 months/or if compromised

[0053] PC (personal computer) based software programs exist thatprovision both mobile stations and infrastructure system devices withkeys. A more secure method utilizes the capabilities of the Key VariableLoader (KVL), or key loader for short, to load keys into theinfrastructure devices as well as the MS. The key loader has a hardwarebased encryption device for the securing of keys stored within thedevice. The KVL may obtain keys directly from the KMF acting as a storeand forward agent in order to disseminate the key encryption keys to thevarious devices.

[0054] Although a KVL is a very secure way to provide keys, it is a verytime consuming process to use one or more KVLs to provide keys at eachsystem device and mobile station. A method of key management is neededto store and distribute the KEKs and other key material to systemdevices such as zone controllers and base sites.

[0055] The KMF 101 is responsible for the generation, key distribution,and tracking of most of the air interface keys (not DCK or MGCK) in thesystem. The base sites 115 and 117 and each zone controller 107 serve asa proxy to the KMF 101 for key distribution. The KMF 101 distributes keymaterial to the zones through the UCS 103, ZMs 105 and 119, and/or ATRs113 and 127 depending on the key being distributed. The KMF 101processes acknowledgement information from the ATR 113 and 127 tomaintain currency of the system devices and MSs 401, 403, 405, and 407.FIG. 3 and FIG. 4 show key material storage within the communicationsystem.

[0056] As shown in FIG. 3, the KMF 101 stores a protection key andassociated KEK(s) for each system device. The KMF 101 stores aprotection (infrastructure) key, an interkey, and an intrakey for eachzone controller. For example, the first zone controller 107 isassociated with the keys KI_(ZC1), KEK_(M), and KEK_(Z1). The KMF 101stores these keys encrypted by a hardware key and the first zonecontroller 107 stores KI_(ZC1) and the encrypted KEK_(M) and KEK_(Z1).The KMF 101 stores a protection key and intrakey, both protected by ahardware key, for each BS. For example, the KMF 101 and the first BS 115both store the protection key KI_(BS1) and the intrakey KEK_(Z1). In thepreferred embodiment, the KMF 101 stores keys encrypted/protected by ahardware key.

[0057] Prior to distribution of a KEK in the preferred embodiment, theKMF 101 encrypts KEKs with the protection key, KI, and the use ofencryption algorithms TA41 and TA51, similar to that shown in FIG. 10titled “Distribution of SCK to an individual by an authenticationcentre” and its associated text in the Terrestrial Trunked Radio(TETRA); Voice plus Data (V+D); Part 7: Security, EN 300 392-7 V2.1.1,2000-12 (herein referred to as “TETRA Standard”), which is incorporatedin its entirety herein by reference. The KMF 101 stores an encryptionprocess 301 that combines RSO and the appropriate KEK, KEKN, and KEK-VNutilizing encryption algorithms TA41 303 and TA51 305, yielding SKEK,which is a sealed version of the KEK. RSO, SKEK, KEKN, and KEK-VN areforwarded to the target system device. Curly brackets { } followed by akey name indicate that the material within the curly brackets wascreated using TA41 and TA51 and the key name after the brackets.

[0058] For example, KEK_(Z1) is intended to be transferred to the firstzone controller 107 and BS1 115. RSO, KEK_(Z1), KEK_(Z1)-VN, andKEK_(Z1)N, and KI_(ZC1) are combined utilizing encryption algorithmsTA41 and TA51, yielding SKEK_(Z1). Key material RSO, SKEK_(Z1),KEK_(Z1)-VN, and KEK_(Z1)N are forwarded transparently through ZM1 105to the first zone controller 107, which combines this key material withKI_(ZC1) using TA41 and TA52 (as described in the TETRA Standard),yielding KEK_(Z1), which is stored at ZC1 107. RSO, KEK_(Z1),KEK_(Z1)-VN, and KEK_(Z1)N, and KI_(BS1) are combined utilizingencryption algorithms TA41 and TA51, yielding SKEK_(Z1). Key materialRSO, SKEK_(Z1), KEK_(Z1)-VN, and KEK_(Z1)N are forwarded transparentlythrough ZM1 105 to BS1 115, which combines this key material withKI_(BS1) using TA41 and TA52, yielding KEK_(Z1), which is stored at BS1115. In the preferred embodiment, an unencrypted acknowledgment ofsuccessful receipt of each key is returned to the KMF 101 via the ATR113.

[0059] A block diagram showing key storage within a communication systemis shown in FIG. 4. In particular, storage of session authenticationinformation throughout the communication system is shown. In thepreferred embodiment, session authentication information includes arandom seed, RS, and two session keys, KS for authentication of an MSand KS′ for authentication of the infrastructure, for each mobilestation 401, 403, and 405 (only three are shown due to spaceconstraints, although numerous MSs are part of the system). The sessionauthentication information (SAI) is used to generate a derived cipherkey (DCK) for each MS 401.

[0060] For each MS 401, 403, and 405, the KMF 101 stores an IndividualTETRA Subscriber Identity (ITSI), TETRA Equipment Identity (TEI), and anMS authentication key (“MS key”) that is unique to and stored withineach MS 401, 403, and 405. In the preferred embodiment, the airinterface keys and the MS keys are stored in hardware encrypted fashionusing a hardware key KH within the KMF 101. The DVI-XL algorithm,available from Motorola, Inc., is used to encrypt the keys for storagein the KMF 101 in the preferred embodiment. Square brackets [ ] followedby a key name indicate that the material within the square brackets isencrypted by that key.

[0061] The KMF 101 generates session authentication information for eachMS 401, 403, and 405, which SAI is at least partially encrypted andforwarded in non-real time to the UCS 103 for storage. For each MS 401,403, and 405, the UCS 103 stores the ITSI, TEI, and ID of the HLRassociated with each MS, as well as the SAI. In the preferredembodiment, KS and KS′ are stored encrypted by the interkey (as receivedfrom the KMF 101) at the UCS 103 for fast and easy transport, and RS isstored unencrypted. The UCS 103 is a transparent device in the preferredembodiment, thus it performs no encryption or decryption functions. Inorder to eliminate potential double entry of information, the KMF 101receives configuration information from the UCS 103. Examples ofconfiguration information are: Individual TETRA Subscriber Identity(ITSI), Group TETRA Subscriber Identity (GTSI), home zone, and zonemanagers. The KMF uses a table lookup, such as a DNS (Domain NameServer) lookup table, to obtain the ATR 113 and 127 addresses. Thedistribution of each of the different key types has differentconfiguration requirements, as described herein.

[0062] The UCS 103 forwards the appropriate SAI to each ZM 105 innon-real time, based on the HLR ID associated with each MS 401. The ZM105, like the UCS 103, is a transparent device and performs noencryption or decryption functions. The ZM 105 stores, for each MShaving the HLR 109 as its home location, an ITSI, TEI, and SAI. In thepreferred embodiment, KS and KS′ are stored encrypted by the interkey(as received from the UCS 103) at the ZM 105 or 119 for fast and easytransport, and RS is stored unencrypted.

[0063] The ZM 105 forwards the SAI to the HLR 109 in non-real time. TheHLR 109 stores an ITSI and the SAI for each MS 401, 403, and 405. In thepreferred embodiment, KS and KS′ are stored encrypted by the interkey(as received from the ZM 103) at the HLR 109, and RS is storedunencrypted. In the preferred embodiment, RS, KS, and KS′ are storedunencrypted at the VLR 111 for faster authentication. In an alternativeembodiment, KS and KS′ may be stored unencrypted at the HLR 109 forfaster authentication.

[0064] When an MS 401 is authenticated at the zone, a new DCK for the MS401 is generated by the VLR 111 at the zone controller 107 from the SAIin real time, after any encrypted SAI is decrypted due to transfer ofthe SAI from the HLR 109. (The ITSI, SAI, and previous DCK associatedwith that MS 401 are forwarded to the VLR 111 in real time before thenew DCK is created.) The ITSI, SAI, and new DCK are forwarded to the HLR109 in real time for storage. In the preferred 15 embodiment, the ITSI,SAI, and DCK comes from the HLR for the MS 401, thus this informationmay come from a different zone if the MS 401 does not use the HLR 109for its home. When the SAI/DCK comes from a different zone, that zonedecrypts/encrypts the information, as necessary, with the interkey fortransport to the appropriate zone, which also provides appropriatedecryption/encryption within the zone. DCK is stored encrypted by theintrakey KEK_(Z) for the zone in which it is stored, for easy and fasttransport to the local BS 115 or 117. In the example shown in FIG. 4,each DCK is stored encrypted by KEK_(Z1). In the preferred embodiment,KS and KS′ are always encrypted with the interkey KEK_(M), for fast andeasy transport during the authentication process, even when transfer iswithin the same zone.

[0065] During the authentication process, the BS 115 communicating withthe MS 401 receives, from ZC1 107 in real time, the MS's 401 DCK,encrypted by the intrakey KEK_(Z1). The BS 115 stores the ITSI and DCKunencrypted for immediate use while the MS 401 is at the coverage areaof the BS 115. See FIG. 17 and its associated text for informationregarding key persistence at each site.

[0066] Each MS 401, 403, and 405 stores its own ITSI, TEI, and DCK inunencrypted form, and K is stored in scrambled or encrypted form. EachMS 401, 403, and 405 also stores in unencrypted form relevant CCKs,GCKs, MGCKs, and SCKs as they are received. These keys may be storedencrypted in the infrastructure in an alternative embodiment.

[0067] The zone controller 107 is responsible for the real timedistribution of keys and mobility management thereof. It maintains keysthat may need to be distributed in a real-time manner necessary whenroaming, for example. The group cipher key is an element in eachtalkgroup record and is kept in the talkgroup HLR. The common cipher keyis a zone or site specific key and is maintained in the zone controlleras well. The ZC is responsible for the creation of the MGCK (based uponthe GCK and CCK) and the distribution to the sites.

[0068] Because keys reside in the talkgroup and individual HLR 109, thezone controller 107 is not transparent with respect to the encryption ofkey material. The ZC 107 maintains a protection key, KI, and twoinfrastructure key encryption keys, interkey KEK_(M) and intrakeyKEK_(Z), for the distribution of key material. KI is used to seal(encrypt) KEK_(M) and KEK_(Z) when they are sent from the KMF 101. Mostkey information is encrypted by the KMF 101 with the interkey, KEK_(M).The zone controller 107 decrypts the key material using KEK_(M) andre-encrypts the same information using KEK_(Z) when sending theinformation to a site within the zone. Thus, the zone controller 107 hasthe TETRA algorithms used for the encryption/decryption ofinfrastructure keys (such as TA41 and TA52 and TA31 and TA32), asdescribed herein.

[0069] The zone controller sends ACKs from infrastructure re-keyingoperations to the KMF 101 via the ATR 113. When a ZC 107 or HLR 109receives a key update, the device first decrypts key update and checksfor corruption by verifying the integrity of the data and sends theresult of this operation to the KMF 101 via the ATR 113 in the form ofan ACK.

[0070] The site is one endpoint for air interface encryption. Audio onthe air interface between the BS 115 and MS 401 is encrypted. Audiowithin the infrastructure is not encrypted. Outbound traffic isencrypted with algorithms using MGCK, CCK, and SCK, or DCK forindividual calls. All inbound traffic is encrypted with algorithms usingDCK or SCK. The site maintains the traffic algorithms and key storagefor SCK, CCK, and MGCK, as well as DCK. Because the base site hastraffic key storage, the base site is not transparent with respect tothe encryption of key material. All key material distributed to the basesite is encrypted by the intrakey, KEK_(Z). Thus, the base sitemaintains a protection key, KI, and an interkey, KEK_(Z). Thus, the basesites have the TETRA algorithms used for the encryption/decryption ofinfrastructure keys (such as TA41 and TA52 and TA31 and TA32), asdescribed herein.

[0071] The MS is the other endpoint point for air interface encryption.Outbound traffic is encrypted with algorithms using MGCK, CCK, and SCK,or the DCK if individually addressed. All inbound traffic is encryptedwith algorithms using DCK or SCK, and identities may be encrypted withSCK or CCK. The MS maintains the traffic algorithms and key storage forSCK, CCK, GCK, and MGCK as well DCK.

[0072] The following figures provides examples of the role of the zonecontroller 107 or 121 in some of its key generation, key distribution,and authentication functions, as well as the base site/base station andMS operations in the key generation, key distribution, andauthentication processes.

[0073] A diagram showing an example of key storage and authenticationinformation distribution within a communication system is shown in FIG.5. Session authentication information (RS, KS, and KS′) is needed tofacilitate real-time authentication of the MS 401 by the ZC 107 andreal-time authentication of the system by the MS, as well as mutualauthentication. Triggers for the transfer of SAI may be a manualinitiation by the KMF operator, an automatic fraud trigger from thesystem, or a periodic changing of the SAI by the KMF 101. FIG. 5 showsthe transfer of SAI for two mobile stations, ITSI1 401 and ITSI2 403(both not shown). The KMF 101 encrypts at least a part of the SAI (e.g.,KS and KS′) with the interkey KEK_(M) for the system, and forwards ITS1, ITSI2, RS, and KS and KS′ encrypted by KEK_(M) to the UCS 103. TheUCS 103 stores a copy and forwards it to the home ZM 105 or 119 for eachITSI. Dashed lines within a system device indicate transparent passageof information through the system device. The ZM 105 or 119 also storesa copy and forward it to its ZC 107 or 121, in particular, the HLR 107or 123. The ZC 107 or 121 stores KS and KS′ encrypted along with RS inthe HLR 107 or 123. Once the HLR 109 or 123 receives the SAI, anunencrypted acknowledgement (ACK) is sent, when decryption using KEK_(M)fails, back to the KMF 101 via the ATR 113 or 127 from the zone in whichthe HLR 109 or 123 resides. If a VLR 111 for the MS 403 exists, such asITSI2, the ZC 121 sends KS and KS′ encrypted with the interkey KEK_(M)to the VLR 111. Coordination between a previous authentication sessioninformation and a new authentication session information is not needed.The HLR 109 or 123 only needs one copy of SAI per ITSI registered. TheUCS 103 and ZM 105 or 119 store copies of authentication sessioninformation to provide recovery from system maintenance or failures.

[0074] By providing storage and forwarding of session authenticationinformation and keys in non-real time (i.e., without time constraint)between first-level system devices and in real time (i.e., on demand)between second-level system devices as described above, theauthentication system provides a fault tolerant system that allows forquick fault recovery as well. If the KMF 101, UCS 103, and/or ZMs 105and 119 fail or are separated from the rest of the system, fullauthentication may still be performed without interruption on areal-time basis with the session authentication information, for examplefor MS2 403, stored at the HLR 123 and VLR 111. A failure at any ofthese devices 101, 103, 105, and 119 is not catastrophic, in that thedata stored may be downloaded from any of the other devices that storesthe information. If a zone controller 107, HLR 109, and/or VLR 111experience a fault or failure, the SAI may be immediately downloadedfrom the ZM 105 at the zone. By eliminating the need for the KMF 101 toparticipate in real time in the authentication process, there is lessburden on the KMF 101 and less traffic in general on the communicationlinks between the system devices of the infrastructure.

[0075] A diagram showing authentication information storage andauthentication decision making within a communication system is shown inFIG. 6. Four mobile stations are shown within a system where threemobile stations 401, 403, and 405 use HLR1 109 of the first zonecontroller 107, one mobile station 407 uses HLR2 123 of the second zonecontroller 121, two mobile stations 401 and 403 use VLR1 111, and twomobile stations 405 and 407 use VLR2 125. Storage of SAI is shownthroughout the system devices. Also shown are base station decisionswhether or not to authenticate a mobile at a particular trigger. Forexample, power-up messages, whether encrypted or not, requireauthentication. Any message sent in the clear (i.e., unencrypted)requires authentication. Encrypted roam messages may be implicitlyauthenticated, i.e., the challenge and response mechanism may bebypassed if the encrypted roam message is successfully decrypted by theBS 131. Power-up messages, roam messages, location updates, and othertypes of messages are considered requests to communicate within thecommunication system. When authentication is required, the BS 115, 117,129, or 131 sends a request to authenticate the MS to the infrastructure(to a zone controller in the preferred embodiment). In the event thatthe infrastructure device to which authentication requests are sentbecomes unavailable, e.g., the device fails, is down for maintenance, orthe communication link to the device is not operable, the BS storesauthentication requests during the time period when the infrastructuredevice is not available. When the infrastructure device becomesavailable, e.g., the device is returned to service after a failure ormaintenance or when the communication link comes up, the BS forwards thestored authentication requests to the infrastructure device.

[0076] In one situation shown in FIG. 6, a first MS 401 sends a clear(unencrypted) power-up message to the first BS 115. In the preferredembodiment, authentication of the MS 401 in this situation is required.Because the MS 401 uses HLR 109 in the zone where the BS 115 is located,the session authentication information SAI1 for the MS 401 is forwardedfrom the HLR 109 to the VLR 111 at the zone for completion of theauthentication process.

[0077] The second MS 403 roams from BS1 115 to BS2 117 and sends a clear(unencrypted) roam message to the second BS 117. In the preferredembodiment, authentication of the MS 403 in this situation is required.Because the MS 403 uses the HLR 109 in the zone where the BS 115 islocated, and because the MS 403 roamed from a site serviced by the sameVLR as the new site, the session authentication information SAI2 for theMS 403 is already located in the VLR 111 at the zone for completion ofthe authentication process.

[0078] The third MS 405 sends an encrypted power-up message to the thirdBS 129. In the preferred embodiment, authentication of the MS 405 inthis situation is required. Because the MS 405 uses the HLR 123 in thezone where the BS 129 is located, the session authentication informationSAI3 for the MS 405 is forwarded from the HLR 123 to the VLR 125 at thezone for completion of the authentication process.

[0079] The fourth MS 407 roams from BS2 117 to BS4 131 and sends anencrypted roam message to the fourth BS 131. In the preferredembodiment, (full) authentication of the MS 403 in this situation is notrequired. Instead, the MS 407 is implicitly authenticated, i.e., thechallenge and response mechanism is bypassed if the encrypted roammessage is successfully decrypted by the BS 131. Because the MS 407 usesthe HLR 109 in the zone other than the zone where the BS 131 is located,the encryption key (and if necessary, the session authenticationinformation SAI4) for the MS 407 must be forwarded from that HLR 109 tothe VLR 125 where the MS 407 has roamed for completion of theauthentication process. Typically, at least a part of the SAI isencrypted by the interkey prior to transfer to another zone. If implicitauthentication fails, full authentication of the MS 407 is thenperformed.

[0080] A diagram showing the challenge-and-response process toauthenticate a mobile station by an authentication center in accordancewith the TETRA Standard is shown in FIG. 7. When authenticating an MS707, an authentication center 701, such as a KMF 101, combines themobile authentication key, K, with RS utilizing the encryption algorithmTA11, as defined in the TETRA Standard. The output of the TA11 process703 is KS, which is input with RAND1 (a random number) to the encryptionalgorithm TA12, as defined in the TETRA Standard. The TA12 process 705outputs XRES1, an expected response, and DCK1, a derived cipher key forthe mobile. RAND1 and RS are provided to the MS 707. The MS 707 goesthrough a similar process, by combining its mobile authentication key,K, with RS received from the AuC 701 utilizing the TA11 process 703. TheTA11 process 703 outputs KS, which is input with RAND1 to the TA12process 705. The TA12 process 705 in the MS 707 outputs RES1, a responseto the challenge, and DCK1, the derived cipher key for the mobile. TheMS 707 forwards RES1 to the AuC 701. If XRES1 and RES1 match, the AuC701 sends an authentication pass message to the MS 707, andcommunication over the air interface with the newly created DCK1 maycommence. If XRES and RES do not match, the AuC 701 sends anauthentication fail message to the MS 707, and communication over theair interface with the newly created DCK1 is prohibited, although theold DCK1 may be used upon authentication failure.

[0081] A diagram showing the challenge-and-response process toauthenticate an authentication center by a mobile station in accordancewith the TETRA Standard is shown in FIG. 8. When authenticating an AuC701, such as a KMF 101, an MS 707 combines the mobile authenticationkey, K, with RS utilizing the encryption algorithm TA21, as defined inthe TETRA Standard. The TA21 process 801 outputs KS′, which is inputwith RAND2 (a random number) to the encryption algorithm TA22, asdefined in the TETRA Standard. The TA22 process 803 outputs XRES2, anexpected response, and DCK2, a derived cipher key for the mobile 707.RAND2 is provided to the AuC 701. The AuC 701 goes through a similarprocess, by combining the mobile authentication key, K, for the MS 707with RS utilizing the TA21 process 801. The TA21 process 801 of the AuC701 outputs KS′, which is input with RAND2 to the TA22 process 803. Theoutput of the TA22 process 803 in the AuC 701 is RES2, a response to thechallenge, and DCK1, the derived cipher key for the mobile. The AuC 701forwards RES and RS to the MS 707. If XRES and RES match, the MS 707sends an authentication pass message to the AuC 701, and communicationover the air interface with the newly created DCK1 may commence. If XRESand RES do not match, the MS 707 sends an authentication fail message tothe AuC 701, and communication over the air interface with the newlycreated DCK1 does not take place. A diagram showing SAI distribution andthe authentication process between a communication system and a mobilestation in real time in accordance with the invention is shown in FIG.9. FIG. 9 shows an implementation of the authentication process of theTETRA Standard including how various system devices within theinfrastructure perform within the authentication process. FIG. 9 showshow the ZC 107, including the HLR 109 and VLR 111, and BS 115 act asproxies, or authentication agents, for the KMF 101 in the authenticationprocess. In non-real time, KS and KS′ encrypted by the interkey, and RSare passed along from the KMF 101 to the UCS 103, to the first ZM 105,and to the HLR 109 of the first zone controller 107.

[0082] After the BS 115 sends a request for authentication of the MS 401to the ZC 107, the VLR 111 generates RAND1 and uses KS and RAND1 withthe TA12 process to generate XRES1 and DCK1, in accord with FIG. 7herein, and forwards RAND1 and RS to the BS 115, which forwards RAND1and RS over the air to the MS 401. The MS 401 combines its own K and RSwith the TA11 process to generate KS, then combines RAND1 and KS inaccord with FIG. 7 herein, yielding RES1 and DCK1, and forwards RES1 tothe BS 115, which forwards RES1 to the VLR 111 at the ZC 107. The VLR111 compares RES1 and XRES1, and the result is R1. When RES1 and XRES1match, DCK1 and the SAI for the MS 401 are stored in the VLR 111 and HLR109 and DCK1 (encrypted by the interkey). In the preferred embodiment,DCK1 is encrypted with the intrakey for the first zone prior to beingsent to the BS 115. R1 is forwarded to the BS 115 in acknowledgment thatauthentication passed, and the BS 115 stores DCK1 and sends R1 to the MS401 indicating authentication has passed. When RES1 and XRES1 do notmatch, the VLR 111 discards the newly created DCK1 without storing orforwarding to the BS 115 and forwards R1, a negative acknowledgment ofthe authentication process, to the BS 115, and the BS 115 sends R1 tothe MS 401 indicating authentication has failed.

[0083] To request authentication of the infrastructure, the MS 403 sendsRAND2 to the BS 129, which forwards RAND2 to the VLR 125 in the ZC 121.The VLR 125 looks up RS and KS′ and generates RES2 and DCK2 using theTA22 process in accord with FIG. 8 herein, and forwards RES2 and RS tothe BS 129, which forwards RES2 and RS over the air to the MS 403. TheMS 403 combines RS and its own K with process TA21, yielding KS′, whichis then combined with RAND2 in the TA22 process in accord with FIG. 8herein, yielding XRES2 and DCK2. The MS 403 compares RES2 and XRES2.When RES2 and XRES2 match, the MS 403 sends message R2 to the BS 129 inacknowledgment that authentication passed, the BS 129 sends R2 to the ZC121, and the VLR 125 causes DCK2 and the SAI for the mobile 403 to bestored in the VLR 125 and the HLR 123 for the MS 403 and forwards DCK2to the BS 129, which stores DCK2. In the preferred embodiment, DCK2 isencrypted with the intrakey for the second zone prior to being sent tothe BS 129. When RES2 and XRES2 do not match, the MS 403 sends messageR2 to the BS 129 indicating that authentication failed, the BS 129 sendsR2 to the ZC 121, and the VLR 125 discards the newly created DCK2without sending it to the BS 129.

[0084] In either authentication process, if the VLR 111 in the zonewhere the MS 401 or 403 is presently located does not have SAI storedfor the MS 401 or 403, the VLR 111 obtains the SAI from the HLR for theMS 401 or 403. When the HLR 109 for the MS 401 or 403 is in the samezone, the SAI is simply passed within the ZC 107 to the VLR 111. Whenthe HLR 109 for the MS 401 or 403 is in a different zone, the zone forthe home HLR is determined from a home zone mapping table that maps ITSIto its Home Zone, and the SAI is forwarded to the ZC 107 to the VLR 111.In the preferred embodiment, when the key material is forwarded from theHLR for the MS 401 or 403 to the VLR 111, at least some of the SAI, inparticular KS and KS′, are encrypted with the interkey. When DCK istransferred within a zone, DCK is encrypted with KEK_(Z). Similarly, ifthe zone where authentication takes place is not the home zone for theMS 401 or 403, updated SAI and DCK information will be inter keyencrypted, at least in part, and forwarded to the appropriate VLR. Askeys are passed between devices that require a different encryption key,one device receives a message, decrypts it with one key, and re-encryptsthe result with another key for the next device.

[0085] Mutual authentication, when the MS and infrastructure mutuallyauthenticate each other, is described with respect to FIG. 3 titled“Mutual authentication initiated by SwMI” and FIG. 4 titled “Mutualauthentication initiated by MS” and their associated text of the TETRAStandard. The resultant DCKs (DCK1 and DCK2) of each process arecombined using the TB4 encryption algorithm, and the resulting DCK isused to communicate.

[0086] A diagram showing a key pull within a communication system isshown in FIG. 10. The key pull procedure is used to forward an airinterface key, typically the DCK, although the process may also be usedfor GCK/MGCK, into a BS that does not have the DCK for a mobile station.This situation may occur when an MS switches sites while idle or afailure arises. FIG. 10 shows MS1 401 switching from site 1 to site 2within zone 1 and MS2 403 roaming from zone 2 to zone 1. Although KS,KS′, and DCK are stored encrypted at the HLR, and DCK is storedencrypted at the HLR and VLR in the preferred embodiment, they are shownunencrypted in FIG. 10 for the sake of simplicity. MS1 401 has roamedfrom site 1 to site 2 in zone 1. The pull procedure is initiated by theBS 117 when it recognizes that it does not have the DCK for the MS 401that has sent an encrypted message, for example, a DCK-encryptedlocation update message. The BS 117 may optionally forward anacknowledgment of receipt of the encrypted message to the mobile station401. The identity, ITSI1, of the MS 401 is encrypted with CCK, so the BS117 is able to determine which MS has sent the message, even though itdoes not have DCK1 for the MS 401. The BS 117 requests the DCK1 from theZC 107. The ZC 107 determines if it needs to request DCK1 from adifferent zone. In this case, because MS1 401 is roaming within the samezone, DCK1 is found in the VLR 111, and the ZC 107 sends DCK1 to the BS117 encrypted with the intrakey KEK_(Z1). The BS 117 uses DCK1 todecrypt the location update message for MS1 401, and any subsequentmessage(s) from the MS 401, and forwards the location update to the ZC107. In the preferred embodiment, the VLR 111 for the MS 401 is notupdated with the MS location until the MS implicitly authenticates orperforms a full authentication. Receipt of a properly decrypted locationupdate message is considered an implicit authentication, at which timethe VLR 111 would be updated. MS2 403 has roamed from zone 2 to zone 1.The pull procedure is initiated by the BS 115 when it recognizes that itdoes not have the DCK for the MS 403 that has sent an encrypted message,for example, a DCK-encrypted location update message. The BS 115 mayoptionally forward an acknowledgment of receipt of the encrypted messageto the mobile station 403. The identity, ITSI2, of the MS 403 isencrypted with CCK, so the BS 115 is able to determine which MS has sentthe message, even though it does not have DCK2 for the MS 403. The BS115 requests the DCK2 from the ZC 107. The ZC 107 determines if it needsto request DCK2 from a different zone, which is required in this case,because MS2 403 is roaming from a different zone, zone 2, and the HLR123 for the MS 403 is in zone 2. The ZC 107 determines which zone hasthe needed key material and sends a request to that target zone for thekey material. In the example, DCK2 is found in the HLR 123 for zone 2,which is the target zone, and DCK2 is sent to the ZC 107 from thatzone's HLR 123 after being encrypted with interkey, KEK_(M). The ZC 107sends DCK2 to the BS 115 encrypted with the intrakey KEK_(Z1). The BS115 uses DCK2 to decrypt the location update message for MS2 403, andany subsequent message(s) from the MS 403, and forwards the locationupdate to the ZC 107. RS, KS, KS′ are requested at a later time from theHLR 123 so that a full authentication may be performed as necessary. Inthe preferred embodiment, the VLR 111 for the MS 403 is not updated withthe MS location until the MS implicitly authenticates or performs a fullauthentication. Receipt of a properly decrypted location update messageis considered an implicit authentication, at which time the VLR 111would be updated.

[0087] In the situation where it may be desired to pull a GCK/MGCK, theprocess is the same as described above with respect to the DCK, exceptthat the VLR 111 obtains the GCK, combines it with a CCK, as describedbelow in FIG. 15 and its associated text, and forwards the resultantMGCK, encrypted with the intrakey KEK_(Z1), to the BS 115 or 117.

[0088] A diagram illustrating a key push within a communication systemis shown in FIG. 11. The key push procedure is used to forward a key,such as the DCK or GCK/MGCK, to a forwarding site when an MS switchessites from its current site to the forwarding site. This process thusprovides a mechanism for a key to be forwarded to a site prior to thearrival of the MS 401 or 403, so that seamless encrypted handoffs androaming may occur. FIG. 11 shows an example of a transfer of DCK2between zones and a transfer of DCK1 within a zone. The MS initiates theprocedure. Although KS, KS′, and DCK are stored encrypted at the HLR,and DCK is stored encrypted at the HLR and VLR in the preferredembodiment, they are shown unencrypted in FIG. 11 for the sake ofsimplicity. 20

[0089] MS1 401 begins the process of roaming from BS1 115, havingLocation Area Identification 1 (LAID1), at site 1 to BS2 117, havingLocation Area Identification 2 (LAID2) at site 2 at zone 1. The MS 401sends to BS 1 115 a message indicating that MS1 will roam to site 2. Inthe preferred embodiment, this message is an OTAR Prepare message. TheBS 115 relays this message to the ZC 107. The ZC 107 determines if theDCK needs to be transferred to another zone or not by determiningwhether or not the site to which the MS 401 is roaming is in its zone ornot. In this example, site 2 is also serviced by the ZC 107, thus thereis no need to transfer the DCK to another zone. Because the DCK istransferred within the zone, the ZC 107 responds to the BS 115 with ause short delay message. In this case, the BS 115 holds off the MS 401from switching to site 2 by a delay equivalent to the short delay, whichdelay approximates the time it will take to forward DCK to the next sitefrom the VLR 111 in the same zone. In the preferred embodiment, theshort delay is less than 50 ms. The MS 401 waits for an ok from the BS115 before operating at the new site, e.g., roaming, switching sites, orcommunicating, and the BS 115 sends the ok after the short delay periodexpires. During the delay period, the VLR 111 at ZC1 107 encrypts DCK1with the intrakey and forwards it to BS2 117 at site 2, where the MS 401and BS2 117 will be able to exchange encrypted messages using DCK1. Inthe preferred embodiment, the VLR 111 for the MS 401 is not updated withthe MS location until the MS 401 implicitly authenticates or performs afull authentication.

[0090] MS2 403 begins the process of roaming from BS3 129, havingLocation Area Identification 3 (LAID3) at site 3 at zone 2 to BS1 115,having Location Area Identification 1 (LAID1) at site 1 at zone 1. TheMS 403 sends to BS3 129 a message indicating that MS2 will roam tosite 1. In the preferred embodiment, this message is an OTAR Preparemessage. The BS 129 relays this message to the ZC 121. The ZC 121determines if the DCK needs to be transferred to another zone or not bydetermining whether or not the site to which the MS 401 is roaming is inits zone or not. In this example, site 1 is not serviced by the ZC 121,thus there is a need to transfer the DCK to another zone. Because theDCK is transferred to another zone, the ZC 121 responds to the BS 129with a use long delay message. In this case, the BS 129 holds off the MS403 from switching to site 1 by a delay equivalent to the long delay,which delay approximates the time it will take to forward DCK from theVLR 111 to the site in the next zone. In the preferred embodiment, thelong delay is greater than or equal to 50 ms. The MS 403 waits for an okfrom the BS 129 before switching sites, and the BS 129 sends the okafter the long delay period expires. During the delay period, the VLR125 at ZC1 121 encrypts DCK2 with the interkey and forwards it to ZC1107, which decrypts it with the interkey, encrypts it with the intrakeyKEK_(Z1), and forwards the result to BS1 115 at site 1, where the MS 403and BS2 115 will be able to exchange encrypted messages using DCK2. Inthe preferred embodiment, the VLR 111 for the MS 403 is not updated withthe MS location until the MS 403 implicitly authenticates or performs afull authentication, at which time the VLR 125 for MS2 in ZC2 121 iseliminated. RS, KS, KS′ are requested at a later time from the HLR atZC3 223 (the home zone HLR for the MS 403) so that a full authenticationmay be performed as necessary.

[0091]FIG. 12 is a diagram showing distribution of a static cipher keyto a BS within a communication system. The SCK is a system wide voicetraffic key that is used to encrypt voice, data, ESI (encrypted shortidentity), and signaling traffic when authentication is not available.SCKs are identified by SCKN and SCK-VN, and are stored in the KMF 101encrypted by a hardware key and in the ZMs 105 and 119 encrypted byTA31. In the preferred embodiment, there may be up to 32 distinct SCKsin the entire system. Each BS stores one SCK, identified by SCK number(SCKN), each of which has an SCK version number (SCK-VN), although SCKmay have multiple versions that are or were used in the system. EachSCKN has a version number SCK-VN, and in the preferred embodiment, twoversion numbers, i.e., two keys, are stored for each SCKN. The MS mustbe able to store 32 SCKs for one SCK-VN, in addition to 32 SCKs foranother SCK-VN. The 31 additional SCKs in the MS are defined for directoperation between mobile stations. A new SCK replaces the oldest SCK-VN.The SCK may be provided to BSs and mobile stations in several ways,including via a Key Variable Loader (KVL), via computer software such asRSS Software available from Motorola, Inc., and via OTAR (Over-the-AirRekeying) via the home zone ATR of the MS. Although not shown in thedrawing because of space constraints, SCKN and SCK-VN are sent alongwith SCK for identification purposes.

[0092] A process to transfer an SCK to each BS in the system is shown inFIG. 12. When the KMF 101 determines that an SCK update is due, the KMF101 generates a new SCK. In order to determine the home zone of a BS, inthe preferred embodiment, the KMF 101 uses the BS to home ZC map fromthe UCS 103 and a table lookup based on the zone to obtain the addressfor the ATR in the zone. The KMF 101 encrypts the SCK with the intrakey,KEK_(Z), for the zone in which the BS is located, and sends theencrypted key to the ZM for that BS. The ZM stores a copy and forwardsit to the intended BS. An unencrypted ACK is sent from the BS to the ZCand to the KMF 101 via the ATR in the zone where the BS resides. The ACKrepresents that the SCK was received correctly in the BS. A specificexample of an SCK transfer to BS1 115 includes a transfer of siteinformation, including an BS to home zone controller map, from the UCS103 to the KMF 101. The KMF 101 uses the map to determine that BS1 115is located in zone 1. The KMF 101 generates the SCK and encrypts it withthe intrakey, KEK_(Z1), for zone 1 where BS1 is located. The KMF 101forwards the encrypted SCK to the ZM 105 for zone 1. ZM1 105 stores acopy of the encrypted SCK and forwards it to BS1 115 via a wirelinelink. BS1 115 decrypts the encrypted SCK using KEK_(Z1) and stores theSCK unencrypted. When the SCK is received correctly by BS1, BS1 115sends an unencrypted ACK to the KMF 101 via ZC1 107 and the ATR 113 inzone 1. Transfers of SCK to BS3 and BS4 are similarly performed.

[0093] A diagram showing distribution of a static cipher key to a mobilestation within a communication system is shown in FIG. 13. When the KMF101 determines that an SCK update for an MS 401 is due, the KMF 101generates a new SCK key material for the MS 401 according to FIG. 10titled “Distribution of SCK to an individual by an authenticationcenter” and its associated text in the TETRA Standard. The SCKgeneration process yields the key material SSCK (a sealed SCK), SCKN(SCK number), SCK-VN (SCK version number), and RSO (the random seed usedin the process). In order to determine the ATR for the home zone of theMS 401, in the preferred embodiment, the KMF 101 uses the ITSI to homeZC map from the UCS 103 and a table lookup based on the zone to obtainthe address of the ATR for the home zone. In the example of FIG. 13, thehome zone for MS1 401 is zone 2. The KMF 101 forwards SSCK, SCKN,SCK-VN, and RSO to the ATR 127 of the home zone (2) for the MS 401. Ifthe MS 401 is not on the system, the ATR 127 sends a NACK back to theKMF 101. If the MS 401 is on the system, the SCK is delivered to the MS401 via the zone in which the MS 401 is currently located. In thepreferred embodiment, the SCK key material (e.g., SSCK, SCKN, SCK-VN,and RSO) are not encrypted for transfer among system devices. The SCKkey material may optionally be encrypted for transfer among systemdevices. When the MS 401 is not located in its home zone, the home zonecontroller 121 of zone 2 determines which zone the MS 401 is currentlylocated in (zone 1 in FIG. 12) by looking it up in the HLR 123 of zone2. ZC2 121 forwards SSCK, SCKN, SCK-VN, and RSO to the zone controller107 of the zone where the MS 401 is presently located. ZC1 107 forwardsSSCK, SCKN, SCK-VN, and RSO to the BS 115 where the MS 401 is located.The BS 115 decrypts the SSCK, SCK-VN, and RSO with the intrakey,KEK_(Z1), and forwards the result to the MS 401. An unencrypted ACK issent from the MS 401 to the BS 115 to the ZC 107 and to the KMF 101 viathe ATR 113 in the zone where the BS 115 resides. The ACK representsthat the SCK was received and unsealed correctly in the MS (theunsealing process is described in the TETRA Standard).

[0094] When the MS 401 is located in its home zone (not shown, butassumed to be at BS3 129 for the sake of this example), the VLR of thehome zone controller 121 forwards SSCK, SCKN, SCK-VN, and RSO to the BS129 where the MS 401 is located (not shown but assumed for thisexample). The BS 129 forwards SSCK, SCKN, SCK-VN, and RSO to the MS 401.An unencrypted ACK is sent from the MS 401 to the BS 129 to the ZC 121and to the KMF 101 via the ATR 127 in the zone where the BS 115 resides.The ACK represents that the SCK was received and unsealed correctly inthe MS (the unsealing process is described in the TETRA Standard).

[0095]FIG. 14 is a diagram showing distribution of a common cipher keyto a mobile station and a BS within a communication system. The CCK is alocation area based traffic key that is used to encrypt voice, data, andsignaling within a location area (LA) and is only used for outboundcommunications. The CCK is meant for use with the encryption of groupcall traffic in the TETRA Standard. The CCK is also used to encrypt thesubscriber identity creating the encrypted short identity (ESI). Groupcall traffic within the LA uses the CCK when there is no GCK availableor it is disabled. There is one CCK per location area. A location areamay be a small as a site, thus there could be as many as CCKs as sitesin the system. It is possible for more than one location area to havethe same CCK. CCK is identified by CCK-ID (e.g., CCK1, CCK2, and soforth) and LAID (location area identification). Two copies of each CCK(the latest two CCK-IDs) are in the ZC and the BS to enable a gradualrekeying of the MS in the system. While one CCK is in use, the next oneis distributed to the MS. In the preferred embodiment, each sitemaintains a CCK for each site adjacent to the site for seamless handoffsbetween sites and to facilitate consistent mobility management. When anadjacent CCK is given to an MS, the latest two CCKs are transferred tothe MS. A new CCK replaces the oldest CCK-ID. Long term storage of CCKsoccurs in the ZMs 105 and 119. The TETRA Standard supports severalmethods to provision CCK over-the-air, and the same request/providemethodology used for each of the air interface keys, and also allows keyrequest upon registration and cell change by the mobile station.

[0096] The CCK to BS procedure illustrated in FIG. 14 is used totransfer a CCK from the KMF 101 to a BS (site) 115. The KMF 101determines that it is time for the CCK of a BS 115 to be updated andgenerates appropriate CCK(s). In the preferred embodiment, each BS is aLocation Area (LA) and has its own Location Area Identification (LAID).FIG. 14 shows the transfer of CCK1 and CCK2 to zone 1 and the transferof CCK3 to zone 2. The CCKs are encrypted with the intrakey, KEK_(Z),for the zone where the LA is located. The UCS 103 provides asite-to-zone map and an ZM-to-zone map to the KMF 101. The KMF 101 usesthese maps to send the keys directly to the appropriate ZM 105 or 119,which stores CCK and forwards CCK to the zone controller 107 or 121. TheUCS 103 obtains the site parameters from the ZMs 105 and 119 to createthe adjacent site list that is sent to the KMF 101 and forwarded the ZMs105 and 119 to be forwarded to the zone controllers 107 and 121 for use.If an adjacent site is in a different zone, the key is transferredbetween the involved ZCs. The ZC encrypts the CCK with the interkey,KEK_(M), for transfer between zone controllers. Using the adjacent sitelist, the zone controllers 107 and 121 send the adjacent site CCKs tothe appropriate sites. Thus, each site on the adjacent site list willhave the CCKs for sites adjacent to that site. The adjacent CCKs areused so that the MS may request the CCK for the adjacent site before theMS switches sites. The BS 115 may also forward CCKs to MSs as new CCKsare received at the BS 115. CCKs are encrypted with DCK for theparticular MS 401 prior to transmitting the encrypted CCK to the MS 401.ACKs are sent by the BS to ZC and are returned to the KMF 101 via theATR (where the BS resides). Because the KMF 101 is unaware of adjacency,it does not need ACKs from adjacent distributions of CCK.

[0097] Because the KMF 101 tracks which BS is given a CCK, the BS tracksthe currency of the CCKs, i.e., which MS has a CCK for a given LocationArea, and forwards ACKs once the CCK is current.

[0098] Because MGCK is a combination of CCK and GCK, the zone controllerwill create four MGCKs using the latest two CCK-IDs and the latest twoGCK-VNs and distribute them accordingly (see FIG. 15 and FIG. 16).

[0099] The CCK is a zone specific parameter so there is no need to gothrough the UCS 103. Thus, the KMF 101 sends the CCK informationdirectly to the appropriate zone manager 105 or 119, which is differentthan the re-keying methodology of other air interface keys. The UCS 103obtains the site information from the zone managers 105 or 119 to createthe adjacent site list. By placing CCKs at adjacent sites, real-timeprocessing of CCKs is reduced, i.e., the BS does not need to query thezone controller for the CCK for an adjacent BS when an MS requests a CCKfor a neighboring site, thus the MS need not process a CCK when the MSswitches sites.

[0100]FIG. 15 is a diagram showing distribution of a group cipher key toa BS within a communication system. GCK is identified by GTSI (GroupTETRA Subscriber ID as referred to in the TETRA standard) and GCK-VN. Inthe preferred embodiment, GCKN is logically equivalent to GTSI from akey management perspective. Long term storage of GCK occurs in the UCSand ZM. MGCK, which is a combination of GCK and CCK, is identified byGTSI (or GCKN), CCK-ID (with LAID), and GCK-VN. Four MGCKs per talkgroup(GTSI) are identified by the latest two CCK-IDs and the latest twoGCK-VNs. MGCKs are not stored in a ZC 107 or 121, but are created by aZC 107 or 121 and sent to the BS 115 provided that an MS affiliated withthat GTSI is at the site of the BS 115, which does not receive the GCKbecause it is a long-term key. Although not shown in the drawing becauseof space constraints, GCK-VN is sent along with GCK and MGCK foridentification purposes.

[0101] The procedure to update a GCK for a talkgroup record has twoparts. The first part includes updating the actual GCK in the for thetalkgroup, the second part includes generating the resultant MGCK as aresult of the update and distributing the MGCK to the sites.

[0102] The procedure of FIG. 15 transfers a GCK from the KMF 101 to thetalkgroup HLR in the zone controller at the home zone for the talkgroup.When the KMF 101 determines that it is time for the GCK to be updated,the KMF 101 generates a GCK for each talkgroup and maintains a GTSI-GCKtable. The GCKs are stored hardware encrypted at the KMF 101. The KMF101 does not know which ZC has the HLR for the GTSI, so the KMF 101sends the GCK encrypted with the interkey, KEK_(M), to the UCS 103. TheUCS 103 stores the key material and forwards it to the home ZM 105 or119 for the talkgroup (GTSI) associated with the GCK. The ZM 105 or 119forwards the key material to its ZC 107 or 121, which stores the keymaterial in the group HLR for GTSI encrypted by KEK_(M). The ZC 107verifies that the key material can be decrypted correctly and sends anACK back to the KMF 101 via the ATR 113 where the group HLR 109 for GTSIresides. The ACK reflects that the HLR 109 contains a correct encryptedcopy of the GCK. The ZC 107 decrypts the key material with KEK_(M) andre-encrypts it with the intrakey, KEK_(Z), for storage in the VLR 111.Any other VLRs, such as VLR2 125, outside of the home zone associatedwith the GTSI will have GCK encrypted with KEK_(M) forwarded to them.FIG. 15 shows both the inter-zone and intra-zone cases.

[0103] Because MGCK is a combination of GCK and CCK generated by a ZCusing the TA71 algorithm 1501, 1503, or 1505, when GCK changes or CCKchanges, the MGCK must also change accordingly. The four MGCKs are sentto all sites having a talkgroup affiliation matching the GTSI for GCK.Because the latest 2 CCK-IDs and latest 2 GCK-VNs are stored, fourversions of the MGCK need to be sent to the BS.

[0104] As in other cases, when sending MGCK to a site, it needs to beencrypted using the intrakey, KEK_(Z) The GCK is obtained from the VLRtalkgroup record and decrypted with the intrakey, KEK_(Z), and combinedwith CCK to create MGCK. The resultant MGCK is encrypted using theintrakey, KEK_(Z), and sent to the appropriate sites.

[0105] Transfer of an MGCK to a BS may be triggered by a number ofevents. Examples of triggers include a mobile station associated withthe GCK for the MGCK residing at the BS when the either the GCK or CCKis generated; a mobile station arriving at the BS when no previoustalkgroup affiliation at that BS had occurred; and a mobile stationchanging talkgroup affiliation, while residing at the BS, to a talkgroupnot previously associated with the BS.

[0106] A diagram showing distribution of a group cipher key to a mobilestation within a communication system is shown in FIG. 16. When the KMF101 determines that an GCK update for an MS 401 is due, the KMF 101generates a new GCK key material for the MS 401 according to FIG. 8titled “Distribution of a group cipher key to an individual” and itsassociated text in the TETRA Standard. The GCK generation process yieldsthe key material SGCK (a sealed GCK), GCKN (GCK Number), GCK-VN (GCKversion number), and RSO (the random seed used in the process). In orderto determine the ATR for the home zone of the MS 401, in the preferredembodiment, the KMF 101 uses the ITSI to home ZC map from the UCS 103and a table lookup based on the zone to obtain the address of the ATRfor the home zone. In the example of FIG. 16, the home zone for MS1 401is zone 2. The KMF 101 forwards SGCK, GCKN, GCK-VN, and RSO to the ATR127 of the home zone (2) for the MS 401. If the MS 401 is not on thesystem, the ATR 127 sends a NACK back to the KMF 101. If the MS 401 ison the system, the GCK is delivered to the MS 401 via the zone in whichthe MS 401 is currently located. In the preferred embodiment, the GCKkey material (e.g., SGCK, GCKN, GCK-VN, and RSO) are not encrypted fortransfer among system devices. The GCK key material may optionally beencrypted for transfer among system devices.

[0107] When the MS 401 is not located in its home zone, the home zonecontroller 121 of zone 2 determines which zone the MS 401 is currentlylocated in (zone 1 in FIG. 16) by looking it up in the HLR 123 of zone2. ZC2 121 forwards SGCK, GCKN, GCK-VN, and RSO to the zone controller107 of the zone where the MS 401 is presently located. ZC1 107 forwardsSGCK, GCKN, GCK-VN, and RSO to the BS 115 where the MS 401 is located.The BS 115 forwards SGCK, GCKN, GCK-VN, and RSO the MS 401. Anunencrypted ACK is sent from the MS 401 to the BS 115 to the ZC 107 andto the KMF 101 via the ATR 113 in the zone where the BS 115 resides. TheACK represents that the GCK was received and unsealed correctly in theMS (the unsealing process is described in the TETRA Standard).

[0108] When the MS 401 is located in its home zone (not shown, butassumed to be at BS3 129 for the sake of this example), the home zonecontroller 121 forwards SGCK, GCKN, GCK-VN, and RSO to the BS 129 wherethe MS 401 is located (not shown but assumed for this example). The BS129 forwards SGCK, GCKN, GCK-VN, and RSO to the MS 401. An unencryptedACK is sent from the MS 401 to the BS 129 to the ZC 121 and to the KMF101 via the ATR 127 in the zone where the BS 115 resides. The ACKrepresents that the GCK was received and unsealed correctly in the MS(the unsealing process is described in the TETRA Standard).

[0109]FIG. 17 is a flowchart showing a method of key persistence at asite in a communication system in accordance with the invention. Keypersistence refers to the time a key remains stored at any system deviceor MS. If an air interface traffic key is deleted from a site when theMS leaves the site, and the key is removed too quickly, the MS mayreturn to the site requiring the key to be set up again. If the MS istraveling between zone borders or site boundaries for a period of time,the key material for the MS may need to be constantly set up if the keymaterial is deleted from a site too quickly after the MS leaves thesite. If the key material is left at a site for too long, duplicate keysmay be set up, creating ambiguity and the likelihood of authenticationfailures, particularly for implicit authentication. Thus, the keypersistence for each key needs to be set adequately to prevent suchproblems. In the preferred embodiment, the persistence time is based onan expected average authentication rate in the communication system, andpreferably the persistence time is less than the expected averageauthentication rate in the communication system. The expected averageauthentication rate is based on an average number of times a mobilestation authenticates within a time period.

[0110] At step 1701, when a MS arrives at a site, key(s) and/or keymaterial associated with the MS 401 are stored at the site. If at step1703 it is determined that the mobile has left the site, a persistencetimer is set at step 1705, unless it had already been set or reset, inwhich case the process simply continues with step 1709. When the timerexpires at step 1707, the process continues with step 1709 where thekey(s) and/or key material associated with the mobile 401 are deletedfrom the site, and the process ends. If the mobile 401 has not left thesite at step 1703, and it is time to replace the mobile's key(s) and/orkey material at step 1711, the key(s) and/or key material are replacedat step 1713 and the process continues with step 1703. Step 1709 mayalso be reached (not shown) if a system device, such as a zonecontroller, directs the site to delete certain key(s) and/or keymaterial for any reason. The zone controller typically determines whenthe mobile leaves a site based on HLR and VLR updates.

[0111] The present invention may be embodied in other specific formswithout departing from its spirit or essential characteristics. Thedescribed embodiments are to be considered in all respects only asillustrative and not restrictive. The scope of the invention is,therefore, indicated by the appended claims rather than by the foregoingdescription. All changes that come within the meaning and range ofequivalency of the claims are to be embraced within their scope.

What is claimed is:
 1. A method comprising the steps of: generating, bya first system device, a first encryption key; forwarding the firstencryption key from the first system device to a second system device;storing the first encryption key at the second system device.
 2. Themethod of claim 1, further comprising the steps of: generating a secondencryption key by combining the first encryption key with a thirdencryption key; forwarding the second encryption key to a third systemdevice.
 3. The method of claim 2, wherein the third system device is anyof a base station, a base site, and a TETRA site controller, wherein thestep of forwarding the second encryption key to a third system device istriggered by a mobile station residing at any of the base station, thebase site, and the TETRA site controller when the first encryption keyis generated, and wherein the mobile station is affiliated with atalkgroup associated with the first encryption key.
 4. The method ofclaim 2, wherein the third system device is any of a base station, abase site, and a TETRA site controller, wherein the step of forwardingthe second encryption key to a third system device is triggered by amobile station arriving at any of the base station, the base site, andthe TETRA site controller, and wherein the mobile station is affiliatedwith a talkgroup associated with the first encryption key.
 5. The methodof claim 2, wherein the third system device is any of a base station, abase site, and a TETRA site controller, wherein the step of forwardingthe second encryption key to a third system device is triggered by amobile station changing talkgroup affiliation while residing at any ofthe base station, the base site, and the TETRA site controller, andwherein the mobile station changes talkgroup affiliation to a talkgroupassociated with the first encryption key.
 6. The method of claim 2,wherein the third encryption key is associated with the third systemdevice.
 7. The method of claim 2, wherein the third encryption key is acommon cipher key.
 8. The method of claim 2, further comprising the stepof communicating over an air interface by encrypting messages with thesecond encryption key.
 9. The method of claim 2, further comprising thestep of updating the first encryption key when an encryption periodassociated with the third encryption key expires.
 10. The method ofclaim 1, further comprising the step of encrypting the first encryptionkey with an interkey, yielding a first encrypted encryption key;forwarding the first encrypted encryption key to a fourth system device;decrypting, by the fourth system device, the first encrypted encryptionkey into the first encryption key.
 11. The method of claim 10, furthercomprising the steps of: generating a second encryption key by combiningthe first encryption key with a third encryption key; forwarding thesecond encryption key to a fifth system device.
 12. The method of claim11, wherein the second encryption key is encrypted with an intrakeyprior to being forwarded to the fifth system device.
 13. The method ofclaim 11; wherein the third encryption key is associated with the fifthsystem device.
 14. The method of claim 11, wherein the third encryptionkey is a common cipher key.
 15. The method of claim 1, furthercomprising the steps of: encrypting the first encryption key with a keyassociated with a mobile station, yielding an encrypted mobileencryption key; forwarding the encrypted mobile encryption key to themobile station.
 16. The method of claim 15, further comprising the stepsof: decrypting, by the mobile station, the encrypted mobile encryptionkey with the key associated with the mobile station, yielding the firstencryption key; combining the first encryption key with a predeterminedencryption key, yielding an air interface key; communicating over an airinterface by encrypting messages with the air interface key.
 17. Themethod of claim 16, wherein the predetermined encryption key is a commoncipher key.
 18. The method of claim 1, further comprising the step ofencrypting the first encryption key with an interkey prior to theforwarding step.
 19. The method of claim 1, further comprising the stepof acknowledging receipt of the first encryption key.
 20. The method ofclaim 19, wherein the step of acknowledging comprising decrypting thefirst encryption key, and when the first encryption key is decryptedproperly, generating an acknowledgment to be forwarded via an airtraffic router to the first system device.
 21. The method of claim 1,-wherein the second system device contains a home location registerassociated with the first encryption key.
 22. The method of claim 1,further comprising the step of updating the first encryption key when anencryption period associated with the first encryption key expires. 23.A method comprising the steps of: generating, by a first system device,key material; forwarding the key material from the first system deviceto a second system device; determining whether a mobile station, forwhich the key material is directed, is active on the system; when themobile station is active, forwarding the key material to a base stationwhere the mobile station is active; forwarding, by the base station, thekey material to the mobile station.
 24. The method of claim 23, furthercomprising the step of encrypting the key material prior to anyforwarding step.
 25. The method of claim 23, wherein any of a base siteand a TETRA site controller takes the place of the base station.
 26. Themethod of claim 23, wherein the key material is forwarded from the firstsystem device to the second system device via an air traffic router. 27.The method of claim 23, wherein the second system device is a zonecontroller.
 28. The method of claim 23, wherein the second system deviceis at least one of a home location register and a visited locationregister.
 29. The method of claim 23, wherein the key material comprisesa group cipher key.
 30. The method of claim 23, wherein the key materialcomprises a static cipher key.
 31. The method of claim 23, wherein thekey associated with the base station comprises an intrakey.
 32. Themethod of claim 23, further comprising the step of encrypting the keymaterial with an interkey prior to forwarding the key material from thefirst system device to the second system device.
 33. The method of claim23, further comprising the step of acknowledging receipt of the keymaterial.
 34. The method of claim 33, wherein the step of acknowledgingcomprising decrypting the key material, and when the key material isdecrypted properly, generating an acknowledgment to be forwarded via anair traffic router to the first system device.
 35. The method of claim23, wherein the second system device contains a home location registerassociated with the mobile station.
 36. The method of claim 23, furthercomprising the step of updating the key material when an encryptionperiod associated with the key material expires.
 37. The method of claim23, further comprising the steps of: generating, by the mobile station,an first encryption key from the key material; combining the firstencryption key with a second encryption key, yielding an air interfacekey; communicating over an air interface by encrypting messages with theair interface key.
 38. The method of claim 37, wherein the firstencryption key is a group cipher key.
 39. The method of claim 37,wherein the first encryption key is a static cipher key.
 40. The methodof claim 37, wherein the second encryption key is a common cipher key.41. The method of claim 37, further comprising the step of updating theair interface key when an encryption period associated with the secondencryption key expires.
 42. The method of claim 23, wherein the step offorwarding the key material from the first system device to a secondsystem device comprises the steps of: forwarding the key material fromthe first system device to a third system device; forwarding the keymaterial from the third system device to the second system device. 43.The method of claim 42, further comprising the steps of: encrypting thefirst encryption key with an interkey prior to forwarding the keymaterial from the first system device; decrypting, by the third systemdevice, the key material with the interkey.
 44. A method comprising thesteps of: generating an encryption key at a first system device;encrypting the encryption key with a first intrakey associated with asecond system device, yielding a first encrypted encryption key;forwarding the first encrypted encryption key to the second systemdevice.
 45. The method of claim 44, further comprising the steps of:encrypting the encryption key with an intrakey associated with a thirdsystem device, yielding a second encrypted encryption key; forwardingthe second encrypted encryption key to the third system device.
 46. Themethod of claim 44, wherein the step of forwarding comprises forwardingthe first encrypted encryption key transparently through at least afourth system device prior to the second system device and storing thefirst encrypted encryption key at the fourth system device.
 47. Themethod of claim 46, wherein the fourth system device is a zone manager.48. The method of claim 44, wherein the encryption key is a staticcipher key that is used when at least one of dynamic air interfaceencryption and authentication is inoperable.
 49. The method of claim 44,wherein the first system device is a key management facility.
 50. Themethod of claim 44; further comprising the step of forwarding anacknowledgment of receipt of the encryption key to the first systemdevice via at least a fifth system device.
 51. The method of claim 50,wherein the fifth system device is an air traffic router.
 52. A methodcomprising the steps of: generating an encryption key at a first systemdevice in a communication system; forwarding the encryption key to asecond system device that serves as a home location register for amobile station; forwarding the encryption key to the mobile station. 53.The method of claim 52, further comprising the step of determiningwhether the mobile station is active in the communication system priorto forwarding the encryption key to the mobile station.
 54. The methodof claim 52, further comprising the step of determining whether themobile station is active in the communication system prior to forwardingthe encryption key to the mobile station, and when the mobile station isnot active, inhibiting forwarding of the encryption key to the mobilestation.
 55. The method of claim 52, wherein the encryption key isencrypted prior to being forwarded.
 56. The method of claim 52, furthercomprising the step of sending an acknowledgment of successful receiptof the encryption key to an air traffic router via at least a zonecontroller
 57. A method comprising the steps of: storing, at a homelocation register, key material related to mobile stations associatedwith the home location register; storing, at a first visited locationregister associated with a first site in a first zone, key materialrelated to a first mobile station of the mobile stations associated withthe home location register; when the first mobile station roams to asecond site in a second zone associated with a second visited locationregister, encrypting key material related to the first mobile stationwith an interkey, yielding encrypted key material; forwarding theencrypted key material to the second visited location register.
 58. Themethod of claim 57, further comprising the steps of encrypting, by thesecond visited location register, the key material with an intrakey,yielding intrakey-encrypted key material, and forwarding theintrakey-encrypted key material to any of a base station and a TETRAsite controller at the second site.
 59. The method of claim 57, furthercomprising the step of, when the mobile station is active at any of abase station, a base site, and a TETRA site controller associated withthe home location register, encrypting, by the first visited locationregister, the key material with an intrakey, yielding intrakey-encryptedkey material, and forwarding the intrakey-encrypted key material to anyof the base station, the base site, and the TETRA site controllerassociated with the home location register.
 60. The method of claim 57,wherein the key material related to mobile stations registered at thefirst home location register is stored at least in part in encryptedform at the home location register.
 61. The method of claim 36, whereinthe key material is stored at least in part unencrypted at the secondvisited location register.
 62. A method comprising the steps of:receiving, from a mobile station at a first site in a communicationsystem, an encrypted message; attempting to decrypt the encryptedmessage; when the attempt to decrypt has at least partially failed,requesting, from a system device in the communication system, anencryption key associated with the mobile station; receiving theencryption key; decrypting the encrypted message with the receivedencryption key.
 63. The method of claim 62, further comprising the stepof exchanging, with the mobile station, messages encrypted with theencryption key.
 64. The method of claim 62, further comprising the stepof decrypting at least an identification of the mobile station in orderto identify the requested encryption key.
 65. The method of claim 64,wherein the identification of the mobile station is decrypted utilizinga common cipher key.
 66. The method of claim 62, further comprising thestep of forwarding an acknowledgment of receipt of the encrypted messageto the mobile station.
 67. The method of claim 62, wherein theencryption key is encrypted by an intrakey prior to the receiving step.68. The method of claim 62, further comprising the steps of: forwardingthe encryption key, encrypted by an interkey, from a system device at afirst zone where the encryption key is stored to a system device at asecond zone including the first site; decrypting, by the system deviceat the second zone, the encrypted encryption key; encrypting, by thesystem device at the second zone, the encryption key with an intrakey,yielding an intrakey-encrypted key; forwarding the intrakey-encryptedkey to a system device at the first site.
 69. The method of claim 62,wherein the encryption key is a derived cipher key.
 70. The method ofclaim 62, further comprising the step of combining a first encryptionkey with a third encryption key, yielding the encryption key.
 71. Themethod of claim 70, wherein the encryption key is a group cipher key.72. The method of claim 62, wherein the system device at the first siteis any of a base station, a base site, and a TETRA site controller. 73.The method of claim 62, further comprising the steps of: determiningwhether the encryption key associated with the mobile station is storedat a zone including the first site; when the encryption key associatedwith the mobile station is not stored at a zone including the firstsite, determining which zone has the encryption key, yielding a targetzone; sending a request to the target zone for the encryption keyassociated with the mobile station; receiving, from the target zone, theencryption key associated with the mobile station.
 74. The method ofclaim 62, wherein the encryption key is stored at the system device atthe first site until the encryption key is replaced by anotherencryption key.
 75. The method of claim 62, wherein the encryption keyis deleted from the system device at the first site after the encryptionkey has not been updated for a period of time greater than an expectedaverage authentication rate in the communication system.
 76. The methodof claim 62, wherein the encryption key is deleted from the systemdevice at the first site when system device at the first site isinstructed to delete the encryption key.
 77. The method of claim 62,wherein the encryption key is deleted after a timeout from the systemdevice at the first site when system device at the first site isinstructed to delete the encryption key.
 78. The method of claim 62,wherein the encryption key is deleted from the system device at thefirst site after the system device at the first site is informed thatthe mobile station has left the first site.
 79. The method of claim 62,wherein the encryption key is deleted after a timeout from the systemdevice at the first site after the system device at the first site isinformed that the mobile station has left the first site.
 80. A methodcomprising the steps of: when a mobile station is located at a site in acommunication system, storing at the site at least one encryption keyassociated with a mobile station; determining when the mobile stationleaves the site; setting a persistence timer; when the persistence timerexpires, deleting the at least one encryption key associated with amobile station.
 81. The method of claim 80, further comprising the stepsof replacing the at least one encryption key with at least anotherencryption key and resetting the persistence timer.
 82. The method ofclaim 80, wherein the persistence timer is set to a persistence timethat is less than an expected average authentication rate in thecommunication system.
 83. The method of claim 80, wherein thepersistence timer is set to a persistence time that is based on anexpected average authentication rate in the communication system. 84.The method of claim 83, wherein the expected average authentication rateis based on an average number of times a mobile station authenticateswithin a time period.
 85. The method of claim 80, wherein the at leastone encryption key is stored at the site until the at least oneencryption key is replaced by at least another encryption key.
 86. Themethod of claim 80, wherein the at least one encryption key is deletedfrom the site when the at least one encryption key has not been updatedfor a period of time greater than an expected average authenticationrate in the communication system.
 87. The method of claim 80, whereinthe at least one encryption key is deleted from the site when a systemdevice at the site is instructed to delete the at least one encryptionkey.
 88. The method of claim 80, wherein the at least one encryption keyis deleted after a timeout from the site when a system device at thesite is instructed to delete the at least one encryption key.
 89. Themethod of claim 80, wherein the step of determining when the mobilestation leaves the site is performed by a zone controller.
 90. A methodcomprising the steps of: sending, by a mobile station at a first site ina communication system, a message indicating intent to roam to a secondsite; forwarding, to a system device at the second site, an encryptionkey associated with the mobile station; exchanging, between the systemdevice at the second site and the mobile station, messages encryptedwith the encryption key.
 91. The method of claim 90, further comprisingthe step of determining a delay period.
 92. The method of claim 91,further comprising the step of, after the delay period, forwarding amessage to the mobile station indicating approval to register at thesecond site.
 93. The method of claim 91, wherein the delay period isbased on a relationship between the first site and the second site. 94.The method of claim 91, wherein the delay period is short when the firstsite and the second site are from one zone in the communication system.95. The method of claim 91, wherein the delay period is long when thefirst site and the second site are from different zones in thecommunication system.
 96. The method of claim 91, wherein the delayperiod is determined by a zone controller for the first site.
 97. Themethod of claim 90, wherein the encryption key is encrypted by anintrakey prior to the forwarding step.
 98. The method of claim 90,wherein the step of forwarding comprises the steps of: encrypting theencryption key with an interkey, yielding an intergroup-encrypted key;forwarding the intergroup-encrypted key from a system device at a firstzone including the first site to a system device at a second zoneincluding the second site; decrypting, by the system device at thesecond zone, the intergroup-encrypted key into the encryption key;encrypting, by the system device at the second zone, the encryption keywith an intragroup encryption key, yielding an intragroup-encrypted key;forwarding the intragroup-encrypted key to the system device at thesecond site.
 99. The method of claim 90, wherein the encryption key is aderived cipher key.
 100. The method of claim 90, further comprising thestep of combining a first encryption key with a third encryption key,yielding the encryption key.
 101. The method of claim 100, wherein theencryption key is a modified group cipher key.
 102. The method of claim90, wherein the system device at the second site is any of a basestation, a base site, and a TETRA site controller.
 103. The method ofclaim 90, wherein the encryption key is stored at the system device atthe second site until the encryption key is replaced by anotherencryption key.
 104. The method of claim 90, wherein the encryption keyis deleted from the system device at the second site when the encryptionkey has not been updated for a period of time greater than an expectedaverage authentication rate in the communication system after the mobilestation leaves the second site.
 105. The method of claim 90, wherein theencryption key is deleted from the system device at the second site whensystem device at the second site is instructed to delete the encryptionkey.
 106. The method of claim 90, wherein the encryption key is deletedafter a timeout from the system device at the second site when systemdevice at the second site is instructed to delete the encryption key.107. The method of claim 90, wherein the encryption key is deleted fromthe system device at the second site after the system device at thesecond site is informed that the mobile station has left the secondsite.
 108. The method of claim 90, wherein the encryption key is deletedafter a timeout from the system device at the second site after thesystem device at the second site is informed that the mobile station hasleft the second site.
 109. A method comprising the steps of: requesting,by a mobile station, to communicate within a communication system in anencrypted manner; determining, by a system device in the communicationsystem, a delay period; after the delay period has expired, forwarding amessage to the mobile station indicating approval to operate.
 110. Themethod of claim 109, wherein the delay period is determined based on arelationship between a location of the mobile station and a storagelocation, within the communication system, of an encryption keyassociated with the mobile station.
 111. The method of claim 109,wherein the delay period is short when the location of the mobilestation and a location of the encryption key are in one zone in thecommunication system.
 112. The method of claim 109, wherein the delayperiod is short when the location of the mobile station and an expectedfuture location of the mobile station are in one zone in thecommunication system.
 113. The method of claim 109, wherein the delayperiod is long when the location of the mobile station and a destinationof the encryption key are in different zones in the communicationsystem.
 114. The method of claim 109, wherein the delay period is longwhen the location of the mobile station and an expected future locationof the mobile station are in different zones in the communicationsystem.
 115. The method of claim 109, wherein the delay period isdetermined by a zone controller.
 116. A method comprising the steps of:dividing a plurality of system devices into a plurality of pools;utilizing an intrakey to encrypt messages passed between system devicesin the same pool; utilizing an interkey to encrypt messages passedbetween system devices of different pools.
 117. The method of claim 116,wherein each of the plurality of pools comprises a mutually exclusivesubset of the plurality of system devices.
 118. The method of claim 116,wherein the messages comprise at least one encryption key.
 119. Themethod of claim 116, wherein the messages comprise sessionauthentication information.
 120. The method of claim 116, wherein eachdifferent pool utilizes a different intrakey.
 121. The method of claim116, wherein only one system device from each pool utilizes theinterkey.
 122. The method of claim 116, wherein the plurality of systemdevices are part of a communication system infrastructure that providesencrypted communications.
 123. The method of claim 116, wherein at leastone of the plurality of system devices has its own protection key, whichprotection key is utilized to encrypt and decrypt any of the intrakeyand the interkey for transport to any of the at least one of theplurality of system devices.
 124. The method of claim 116, wherein eachpool of the plurality of pools is comprised of one or more systemdevices that reside in a single zone of a plurality of zones in acommunication system.
 125. The method of claim 124, wherein the one ormore system devices that reside in a single zone are comprised of atleast one of a base station, base site, TETRA site controller, and azone controller.
 126. The method of claim 124, wherein only a zonecontroller within each of the plurality of zones stores the interkey.127. The method of claim 116, wherein the interkey is utilized toencrypt messages passed between a system device and a key managementfacility.
 128. The method of claim 116, wherein a message is encryptedby one of an intrakey and an interkey based on a system device to whichthe message is forwarded.
 129. A method comprising the steps of: storinga protection key for each of a plurality of system devices; whentransporting key material to a system device of the plurality of systemdevices, encrypting the key material with a protection key associatedwith the system device.
 130. The method of claim 129, wherein the keymaterial is a key encryption key.
 131. The method of claim 129, whereineach of the plurality of system devices has its own unique protectionkey.
 132. A method comprising the steps of: establish an expectedlifetime for an encryption key; determining a number of storagelocations for each type of system device within a communication system;based on the expected lifetime for the encryption key and the number ofstorage locations, assigning the type of system device at which to storethe encryption key; storing the encryption key at a system device of theassigned type.
 133. The method of claim 132, wherein the step ofdetermining comprises determining a number of storage locations andaccessibility for each type of system device within a communicationsystem, and the step of assigning comprises, based on the expectedlifetime for the encryption key and the number of storage locations andaccessibility, assigning the type of system device at which to store theencryption key.
 134. The method of claim 132, further comprising thestep of replacing the encryption key when its expected lifetime expires.135. The method of claim 132, wherein the encryption key is a derivedcipher key that is stored at any of a base station, a base site, and aTETRA site controller.
 136. The method of claim 132, wherein theencryption key is a common cipher key that is stored at any of a basestation, a base site, and a TETRA site controller.
 137. The method ofclaim 132, wherein the encryption key is a modified group cipher keythat is stored at any of a base station, a base site, and a TETRA sitecontroller.
 138. The method of claim 132, wherein the encryption key isa group cipher key that is stored at at least one of a home locationregister and a visited location register.
 139. A method comprising thesteps of: generating an encryption key for use in a first geographicalarea; forwarding the encryption key to one or more base stationscovering the first geographical area; transmitting, by at least one ofthe one or more base stations, the encryption key to a mobile stationregistered at the at least one of the one or more base stations. 140.The method of claim 139, wherein any combination of one or more basesites and one or more TETRA site controllers takes the place of the oneor more base stations.
 141. The method of claim 139, wherein theencryption key is encrypted with an interkey prior to the forwardingstep.
 142. The method of claim 141, further comprising the steps ofdecrypting the encrypted encryption key, and encrypting the encryptionkey with an intrakey prior to the forwarding step.
 143. The method ofclaim 139, wherein the encryption key is encrypted prior to thetransmitting step.
 144. The method of claim 143, wherein the encryptionkey is encrypted with a derived cipher key prior to the transmittingstep.
 145. The method of claim 139, further comprising the step ofsending an acknowledgment of receipt of the encryption key to a keymanagement facility.
 146. The method of claim 145, further comprisingthe step of checking currency of the encryption key and holding off thestep of sending until the encryption key is current.
 147. The method ofclaim 145, wherein the step of sending the acknowledgment comprisessending the acknowledgment to an air traffic router via at least a zonecontroller.
 148. The method of claim 139, further comprising the stepsof generating a second encryption key for use in a second geographicalarea adjacent to the first geographical area, and forwarding the secondencryption key to one or more base stations covering the secondgeographical area.
 149. The method of claim 148, further comprising thestep of forwarding the second encryption key to at least one of the oneor more base stations covering the first geographical area.
 150. Themethod of claim 139, further comprising the step of tracking, by thebase station, currency of the encryption key.
 151. The method of claim139, wherein the encryption key is a common cipher key.
 152. The methodof claim 139, wherein each base station stores an encryption keyassociated with each geographical area adjacent to the geographical areacovered by the base station.
 153. A method comprising the steps of:generating a plurality of encryption keys and associating eachencryption key with one geographical area of a plurality of geographicalareas; forwarding each encryption key to one or more base stations inthe geographical area associated with the encryption key; determining atleast one of the plurality of geographical areas that is adjacent to afirst geographical area, yielding one or more adjacent geographicalareas; forwarding an encryption key for at least one of the one or moreadjacent geographical areas to at least one base station covering thefirst geographical area.
 154. The method of claim 153, wherein anycombination of one or more base sites and one or more TETRA sitecontrollers takes the place of the one or more base stations.
 155. Themethod of claim 153, further comprising the step of transmitting, by atleast one of the one or more base stations, the encryption key to amobile station registered at the at least one of the one or more basestations.
 156. The method of claim 155, wherein each encryption key isencrypted with at least one of an interkey and an interkey prior to theforwarding step.
 157. The method of claim 156, further comprising thesteps of decrypting the encrypted encryption key, and encrypting theencryption key with an intrakey prior to the forwarding step.
 158. Themethod of claim 153, wherein each encryption key is encrypted prior tothe transmitting step.
 159. The method of claim 158, wherein eachencryption key is encrypted with a derived cipher key prior to thetransmitting step.
 160. The method of claim 153, further comprising thestep of sending an acknowledgment of receipt of the encryption key to akey management facility.
 161. The method of claim 160, wherein the stepof sending the acknowledgment comprises sending the acknowledgment to anair traffic router via at least a zone controller.
 162. The method ofclaim 153, further comprising the step of tracking, by a base station,currency of the encryption key.
 163. The method of claim 153, whereinthe encryption key is a common cipher key.
 164. The method of claim 153,wherein each base station stores an encryption key associated with eachgeographical area adjacent to the geographical area covered by the basestation.